home *** CD-ROM | disk | FTP | other *** search
/ Aminet 31 / Aminet 31 (1999)(Schatztruhe)[!][Jun 1999].iso / Aminet / dev / c / vbccppc.lha / vbcc / doc / interface.doc < prev    next >
Text File  |  1999-03-07  |  29KB  |  810 lines
  1. (c) in 1995-99 by Volker Barthelmann
  2.  
  3. This document is under construction!
  4.  
  5. This document describes some of the internals of vbcc and tries to explain
  6. what has to be done to write a code generator for vbcc.
  7. However if someone wants to write one, I suggest to contact me first,
  8. so that it can be integrated into the source tree.
  9.  
  10. You have to create a new directory for the new target named
  11. machines/<target-name> and write the files machine.c, machine.h
  12. and machine.dt. The compiler for this target will be called
  13. vbcc<target-name> and can be built by the statement
  14. "make TARGET=<target-name> bin/vbcc<target-name>".
  15.  
  16. From now on integer means any of {char, short, int, long} or their
  17. unsigned couterparts. Arithmetic means integer or float or double.
  18. Elementary type means arithmetic or pointer.
  19. If you intend to write a code generator for a machine with multiple
  20. different kinds of pointers you might have some problems.
  21.  
  22.  
  23. THE INTERMEDIATE CODE
  24.  
  25. vbcc will generate intermediate code for every function and pass this code
  26. to the code generator which has to convert it into the desired output.
  27.  
  28. In the future there may be a code generator generator which reads a machine
  29. description file and generates a code generator from that, but it is not
  30. clear whether this could simplify much without taking penalties in the
  31. generated code.
  32. Anyway this would be a layer on top of the current interface to the code
  33. generator so that the interface described in this document would still be
  34. valid and accessable.
  35.  
  36. The intermediate code is represented as a doubly linked list of quadruples
  37. (I am calling them ICs from now on) consisting mainly of an operator, two
  38. source operands and a target. They are represented like this:
  39.  
  40. struct IC{
  41.     struct IC *prev;
  42.     struct IC *next;
  43.     int code;
  44.     int typf;
  45.     [...]
  46.     struct obj q1;
  47.     struct obj q2;
  48.     struct obj z;
  49.     [...]
  50. };
  51.  
  52. The only members relevant to the code generator are 'prev', 'next', 'code',
  53. 'typf', 'q1', 'q2' and 'z'.
  54.  
  55. 'prev' and 'next' are pointers to the previous and next IC.
  56. The first IC has 'prev'==0 and the last one has 'next'==0.
  57.  
  58. 'typf' is the type of the operands of this IC. This can be one of:
  59.  
  60.     #define CHAR 1
  61.     #define SHORT 2
  62.     #define INT 3
  63.     #define LONG 4
  64.     #define FLOAT 5
  65.     #define DOUBLE 6
  66.     #define VOID 7
  67.     #define POINTER 8
  68.     #define ARRAY 9
  69.     #define STRUCT 10
  70.     #define UNION 11
  71.     #define ENUM 12         /*  not relevant for code generator     */
  72.     #define FUNKT 13
  73.  
  74.     and can be additionally or'ed by
  75.  
  76.     #define UNSIGNED 16
  77.     #define CONST 64
  78.     #define VOLATILE 128
  79.     #define UNCOMPLETE 256
  80.  
  81.     However only UNSIGNED is of real importance for the code generator.
  82.     'typf'&NQ yields the type without any qualifiers, 'typf'&NU yields
  83.     the type without any qualifiers but UNSIGNED.
  84.  
  85. 'q1', 'q2' and 'z' are the source1 (quelle1 in German), source2 and target
  86. (ziel).
  87. If a result has to be computed, it always will be stored in the object 'z'
  88. and the objects 'q1' and 'q2' usually may not be destroyed during this
  89. operation.
  90.  
  91. The objects are described by this structure.
  92.  
  93. struct obj{
  94.     int flags;
  95.     int reg;
  96.     struct Var *v;
  97.     struct AddressingMode *am;
  98.     union atyps{
  99.         zchar vchar;
  100.         zchar vuchar;
  101.         zshort vshort;
  102.         zushort vushort;
  103.         zint vint;
  104.         zuint vuint;
  105.         zlong vlong;
  106.         zulong vulong;
  107.         zfloat vfloat;
  108.         zdouble vdouble;
  109.         zpointer vpointer;
  110.     }val;
  111. };
  112.  
  113. 'flags' describes what kind the object is. It can be a combination of
  114.  
  115. #define VAR 1
  116.  
  117.     The object is a variable. The pointer to its struct Var is in 'v'.
  118.     'val.vlong' vontains an offset that has to be added to it.
  119.  
  120.     A struct Var looks like:
  121.  
  122.     struct Var{
  123.         int storage_class;
  124.         [...]
  125.         char *identifier;
  126.         [...]
  127.         zlong offset;
  128.         [...]
  129.     };
  130.  
  131.     The relevant entries are:
  132.  
  133.     'identifier':
  134.  
  135.         The name of the variable. Usually only of interest for variables
  136.         with external-linkage.
  137.  
  138.     'storage_class':
  139.  
  140.         One of:
  141.             #define AUTO 1
  142.             #define REGISTER 2
  143.             #define STATIC 3
  144.             #define EXTERN  4
  145.             #define TYPEDEF 5       /*  not relevant    */
  146.  
  147.         If the variable is not assigned to a register (i.e. bit REG
  148.         is not set in the flags of the corresponding struct obj) then
  149.         the variable can be addressed in the following ways (with
  150.         examples of 68k-code):
  151.  
  152.         'storage_class' == AUTO or 'storage_class' == REGISTER:
  153.  
  154.             'offset' contains the offset inside the local-variables section.
  155.             The code generator must decide how it's going to handle the
  156.             activation record.
  157.             If 'offset' < 0 then the variable is a function argument on the
  158.             stack. In this case the offset in the parameter-area is
  159.              - ('offset' + 'maxalign').
  160.  
  161.             The code generator may have to calculate the actual offset
  162.             to a stack- or frame-pointer from the value in 'offset'.
  163.  
  164.                 'offset'+'val.vlong'(sp)
  165.  
  166.             Note that 'storage_class' REGISTER is equivalent to AUTO - whether
  167.             the variable is actually assigned a register is specified by
  168.             the bit REG in the 'flags' of the 'struct obj'.
  169.  
  170.         'storage_class' == EXTERN
  171.  
  172.             The variable can be addressed through its name in 'identifier'.
  173.  
  174.                 'val.vlong'+_'identifier'
  175.  
  176.         'storage_class' == STATIC
  177.  
  178.             The variable can be addressed through a numbered label. The
  179.             label number is stored in 'offset'.
  180.  
  181.                 'val.vlong'+l'offset'
  182.  
  183. #define KONST 2
  184.  
  185.     The object is a constant. Its value is in the corresponding (to 'typf')
  186.     member of 'val'.
  187.  
  188. #define DREFOBJ 32
  189.  
  190.     The content of the location in memory the object points to is used.
  191.  
  192. #define REG 64
  193.  
  194.     The object is a register. 'reg' contains its number.
  195.  
  196. #define VARADR 128
  197.  
  198.     The address of the object is to be used. Only together with static
  199.     variables (i.e. 'storage_class' STATIC or EXTERN).
  200.  
  201. The possible combinations of these flags should be:
  202.  
  203.         0 (no object)
  204.         KONST
  205.         REG
  206.         VAR
  207.         VAR|REG
  208.         REG|DREFOBJ
  209.         VAR|DREFOBJ
  210.         VAR|REG|DREFOBJ
  211.         VAR|VARADR
  212.  
  213. Also some other bits which are not relevant to the code generator may be set.
  214.  
  215. Constants will usually be in 'q2' if possible. One of the sources always is
  216. not constant and the target is always an lvalue.
  217. Unless otherwise specified all operands of an IC are of the type 'typf'
  218. (which may be further restricted by 'code'). However not all objects have
  219. to be used.
  220. This depends on 'code' and is listed below. In most cases (i.e. when not
  221. explicitly stated) 'typf' is an elementary type (i.e. arithmetic or pointer).
  222.  
  223. 'am' can be used to store information on special addressing modes.
  224. This has to be handled by the by the code generator. However 'am' has to be 0
  225. or has to point to a struct AddressingMode that was allocated using malloc()
  226. when the code generator returns.
  227.  
  228. 'val' stores either the value of the object if it is a constant or an offset
  229. if it is a variable.
  230.  
  231. 'code' describes the operation and can be one of:
  232.  
  233. #define ASSIGN 2
  234.  
  235.     Copy 'q1' to 'z'. 'q2.val.vlong' contains the size of the objects (this is
  236.     necessary if it is an array or a struct). 'typf' does not have to be an
  237.     elementary type!
  238.  
  239.     The only case where 'typf' == ARRAY should be in automatic initializations.
  240.  
  241.     It is also possible that ('typf'&NQ) == CHAR but the size is != 1. This is
  242.     created for an inline memcpy/strcpy where the type is not known.
  243.  
  244. #define OR 16
  245. #define XOR 17
  246. #define AND 18
  247.  
  248.     Bitwise boolean operations. q1,q2->z.
  249.     All operands are integers.
  250.  
  251. #define LSHIFT 25
  252. #define RSHIFT 26
  253.  
  254.     Bit shifting. q1,q2->z. 'q2' is the number of shifts.
  255.     All operands are integers.
  256.  
  257. #define ADD 27
  258. #define SUB 28
  259. #define MULT 29
  260. #define DIV 30
  261.  
  262.     Standard arithmetic operations. q1,q2->z.
  263.     All operands are of arithmetic types (integers or floating point).
  264.  
  265. #define MOD 31
  266.  
  267.     Modulo (%). q1,q2->z.
  268.     All operands are integers.
  269.  
  270. #define KOMPLEMENT 33
  271.  
  272.     Bitwise complement. q1->z.
  273.     All o